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MEMORANDUM FOR: Director, Consolidated SAFE Project Office 


FROM: 


Deputy Director, Consolidated SAFE Project Office 


Director, Information Resources Office 


SUBJECT: [is SAFE System Requirements 


Specification 


1. In the time available, we have reviewed the subject 


documents and offer the following comments and observations for 


your 


consideration: 


a. In view of the statement found on p. 4 of Book I 
that: "In the event of conflict between the documents 
referenced herein and the contents of this specification, 
the contents of this specification shall be considered a 
superseding requirement, except in the case of the SAFE 
Contract," it is our opinion that this set of documents 
will become part of the contract and will henceforth 
govern and determine the actual configuration of the 
systems and the capabilities that both SAFE systems will 
consist of at I10C. The CSRD documents will have validity 
only to the extent that this specification is silent or 
the wording of the Systems Requirements Specification 
can be harmonized with the CSRD. We have not been able to 
make a detailed comparison between the two sets of docu- 
ments to ascertain the exact extent that changes have been 
made. We know that the staff of the CSPO is engaged in such 
a study. We feel that the results of such a study should 
be incorporated in a written memorandum which summarizes 
all significant changes which[__]has made, which the CS POF AHSNTL 
prepared to accept, the rationale therefor, together with an 
analysis of the overall significance of these changes. This 
memorandum should then be provided to the members of the 
Steering Committee for their review prior to government 
acceptance of the Systems Requirements Specification. 


b. In general, the statement of the general system 
requirements and the requirements for SAFE-C seem to provide 
a reasonable set of criteria for directing the detailed 
system design and its evaluation. However, there seem 
to be a large number of items which are designated to be 
implemented "in a simplified manner." Some of these appear 
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to be relatively critical elements of the system, so that a 
written explication of what is meant by a “simplified manner" 
should be required, either as to specific items or a 

general formula, or both. 


c. The SAFE-D specifications, on the other hand, appear 
to us to be too incomplete, even for this stage of the 
project. Given the fact that in its present form these 
documents become the operative part of the contract itself 
insofar as defining the deliverable, the government should 
certainly not approve this portion of the system requirements 
specification until many of the items listed as "TBD" have 
been determined. 


d. I have previously noted the fact that there is no 
electrical interface specified between the SAFE-C and SAFE-D 
systems. In addition to the electrical interface specifi- 
cation, we believe that the ability to implement certain 
functions, such as the capability for analyst-to-analyst 
communication between SAFE-C and SAFE-D terminals and the 
capability for SAFE-C terminals to access data bases resident 
on SAFE-D and vice-versa, should be stated explicitly, even 
though the specification of an electrical interface might 
imply such a capability. Jhe need for this is, in my 
opinion, supported by the results of the IHC Analysts Support 
Study. 


e. Even though SAFE-C, and possibly SAFE-D, are to be 
initially implemented in a system high operational mode, 
both from the aspect of being able to impose the "need-to- 
know" and being able to implement compartmentation controls, 
it is desirable that the system have the capability 
of imposing access controls down to the record level and 
possibly to the sub-element level. It is not clear to me 
from my review that this is provided for, either at I10C 
or beyond. If it is, I would appreciate being informed of 
the specific provision therefor. If not, I would appreciate 
being informed of your estimate of the resource implications 
of including this as a requirement, either for I0C or 
post-10C implementation. 


f. In dealing with the ADSTAR interface, paragraph 
10.3.7.12.3.1 provides that a SAFE user can request "a print 
of an ADSTAR document" or "the display of an ADSTAR document" 
on an ADSTAR terminal. It was my understanding of the 
original concept that when, through an index search, a SAFE 
user had identified a series of documents resident on ADSTAR 
which met the criteria of his search strategy, he would then 
be able to have the system execute a command which would 
permit him to browse the complete list of documents on his 
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ADSTAR terminal or to execute a command to print all of the 
referenced documents without having to re-enter the document 
numbers of each of the references. It appears to us that if 
this is the case, this language should be amended to so 
specify. 


g- While the requirements appear to be quite adequate 
regarding[ _—sJresponsibilities to develop and carry out 
a quality assurance program, the documents seem to imply 
that the CSPO will only be involved in reviewing the 
documentation up to the point of system demonstration 
testing. We believe it advisable to include language which 
indicates that government personnel will be afforded the 
Opportunity to monitor all phases of test and evaluation and 
making provision for additional review and testing if the 
original results are unsatisfactory. 


h. In paragraph 10.3.2.5.4 of the system requirement 
specifications the following statement appears: "The system 
shall mishandle no more than 0.1 percent of transactions 
(user requests for service)." This was derived from CSRD 
VY. 5, paragraph 4.2.3.2.2. We interpret this from its 


context in the CSRD to represent an attempt to define qa STATINTL 


a measurable degree of software reliability. ttempts 

to postpone the attainment of this standard unti OC as 
regards SAFE-C. However, a similar requirement as to SAFE-D 
which prescribes a much more stringent standard is found 

in paragraph 20.3.2.5.4 where it is indicated that this is to 
be "implemented in a simplified manner." If there is to be 
such a specification, it seems to us that it should be 
required to be attained, either at IOC or within a reasonable 
stated time after I0C. Also, there is no specification of 
the manner in which the fulfillment of the requirement jis to 
be judged. For it to have real validity, it would seem to us 
that it could only be deemed to have been satisfied following 
a period of full-scale operational experience, with a 
reasonable opportunity for the contractor to correct some of 
the error in coding which will necessarily escape the most 
stringent test and evaluation program. Regardless of the 
above suggestions, it appears that it would be preferable 

to eliminate the requirement entirely rather than include it 
as a standard to be attained only at FOC. 


i. We are concerned about the statement found in 
paragraph 20.3.2.1.1 that: "The response time requirements 
are only applicable for the current active highest priority 
users.’ This appears to be an attempt to restate the 
language in CSRD, Vol. V, p. 4-1, where it is stated: 
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there has been any modification in 
subsequent to their proposal? 
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"the objective of the DIA SAFE system is to provide the 
lowest possible response times for those activities which 
support the on-line user activities, and reasonable response 
times for all other system activities, depending on their 
criticality to the intelligence processing mission.’ If so, 
it is ambiguously worded and much more restrictive than 
necessary. 


j. Section 10.3.1.2 of the system requirements 
specification states: "The mission of the CIA SAFE 
system is to improve support to intelligence production 
analysts by providing indirect access to other intelli- 
gence community and commercial computer systems." We are 
unable to interpret any of the substantive requirements to 
provide for such access. We would appreciate being advised 
as to whether or not the requirements as presented permit 
the fulfillment of this portion of the stated mission, and 


if so, how this is to be implemented. STATINTL 
2. When we reviewed the proposal, we were concerned 
with the manpower loading proposed by over the course of the 


project since it did not appear to conform with models in the 
literature. There did not appear to be sufficient manpower 
remaining to do error correction coding which jis generally 
required after I0C in the case of SAFE-D. We had thought this 
might be addressed in the management plan. Since it is not, we 
take this opportunity to call it to =a attention and ask if 


s plans in this regard 


3. The DIA portion of the CSRD in Vol. V, Section ees ee fa 


was provided that: "To avoid the current difficulties in multiple 
query language (AIRES, COINS, DIAOLS), the SAFE system should be 
implemented with a common standard language for all subsystems. A 
language interpreter which converts user input commands to the 
form acceptable by the queried system should be developed for 
systems external to SAFE which users wish to access. At I0C this 
capability should be provided for AIRES and selected COINS systems 
to be specified by the government at a Tater date. Post I0C 
development should aim towards expanding this capability to other 
systems." In the matrix, this provision of the CSRD is described 
as "N/A," but Section 20.3.1.5.1.2.2 provides: "The system shall 
provide the capability for transparent access to other systems in 
the Washington Area Local Communications Network. This 
transparent access will initially be provided only to the SOLIS 
and AIRES systems." Presumably the requirement to provide a 
"transparent access" implies a language interpreter be built for 
these two external systems. (Perhaps this should be more 
specific.) It is common knowledge, confirmed by the results of 
the IHC Analyst Support Study, that one of the principal barriers 
to more widespread use by the analytical community of automated 
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data bases is the difficulty of being forced to use a bewildering 
variety of complex retreival languages. The differences among 
these languages are often arbitrary. There are two possible 
approaches to solving this problem. One is the development of 
language translation facilities such as proposed by the above 
quoted CSRD requirement and the COINS ADAPT project, and the 
establishment of a standard user language for the implementation 
of functions which are common to all or most information retrieval 
systems. With the advent of SAFE, a large portion of the 
Community's data bases will be accessible to a very large 
proportion of the Community's analysts, either through SAFE or 
COINS. If the development of the SAFE user language and the 
development of the mechanisms to provide transparent access 
therefrom to the AIRES and the data bases from SAFE-D were 
properly coordinated with the COINS ADAPT project, the result 
would naturally be the establishment of a de facto community 
Standard user language. The development of such a standard to 
which future community systems could be adapted is a very 
substantial contribution to the improvement of information 
handling throughout the Community which SAFE could make. I would 
appreciate discussing this with you in some depth. I suggest_th 
there should be a requirement stated for the coordination of 

work on the SAFE user language and the transparent access to AIRES 


4. I appreciate the opportunity to comment on the 
requirements documents. I hope they will be helpful to you. 


cc: D/DCI/RM 
“7 0/ODP 
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